Method of operation

By establishing the formulation of the assignment in the test plan, it is made clear to all the parties involved (including the client) what the test process is meant to deliver, and expectations are brought into line. The formulation of the test level should be compatible with the formulation of the assignment as set out in the master test plan.

An assignment formulation for a test plan consists of the following elements:

• Client
• Contractor
• Assignment
• Scope
• Preconditions and assumptions

These parts are explained below:

Client - The party who has commissioned the creation of the test plan and the execution of the tests. It is important for the test level to acknowledge who has commissioned the execution of the test.

Contractor - Usually, a test manager or test coordinator is responsible for creating the test plan and executing the test assignment.

Assignment - This should be set up in consultation with the client and should indicate the aims and the scope of the testing.

As test manager, you should ideally gain a feel for what the guiding principle of the project is in terms of BDTM. Is the client mainly concerned with Time or Costs, or is Result/Risk the driving force? This is no easy task, for the initial reaction (“our maximum budget is € …”, and “the deadline of … is set in concrete”) often seems crystal clear, but on further questioning is not always so (“… and if the system then only has ¾ of the functionality?”). Nevertheless, this insight will aid the test manager’s understanding and facilitate later communication on the choices to be made. The sensitivity of this information means that it is not necessarily established in the plan.

Additionally, the test regularly involves secondary requests. The client should allocate budget and/or time available for these. Examples are: 

• The creation of a standard maintenance test plan, to include all the reusable test aspects
• Training and coaching of the employees in testing Improvement and structuring of the test approach employed
• Implementation of a test tool
• The setup, use and maintenance of a scaleable regression test set 
• Supply of (automated) testware for the testing of subsequent releases.

Scope of operation - The limits of the test operation should be indicated here. This should preferably be more specific than what is already stipulated in the master test plan. The following matters should be taken into consideration (where applicable):

• System(s)
• Conversions
• Administrative organisation (AO) procedures
• Quality characteristics (allocated in the master test plan)
• Interfaces with adjacent systems (is the interface being tested up to the other system or up to and including, or even to include the entire chain?)

• System changes that are not included in the project
• Test activities that are carried out by other test levels or parties
• Reorganisations
• Possible future projects that influence the current project (particularly if there is a lack of clarity concerning other projects).

Preconditions - Preconditions describe conditions set by third parties, such as the client, the project, managers or users with regard to the test process and within which the test process must operate.

Assumptions - These are external circumstances or events that must come about in order for the test process to succeed, but that are beyond the control of the test process. In other words, the requirements that the test process sets other parties. The test manager cannot make do with including these points in the plan and then assuming when the plan is accepted that all the points have been organised. On the contrary, he should fi rst agree the points with the parties that own them, so that the points constitute set agreements and not surprises. It is advisable to mention in the plan, per assumption, for which stakeholder or parties these are intended.

Products

The assignment formulation, established in the test plan.

Techniques

Checklist of preconditions and assumptions